Untted States Patent and Trademark Office 



UNITED STATES DEPARTMENT OF COMMERCE 
United States Patent and Trademark Office 
Address: COMMISSIONER FOR PATENTS 
P.O. Box 1450 

Alexandria, Virginia 22313-1450 
www.uspto.gov 



APPLICATION NO. 



FILING DATE 



FIRST NAMED INVENTOR 



ATTORNEY DOCKET NO. 



CONFIRMATION NO. 



10/632,412 



07/31/2003 



7590 



07/25/2006 



HEWLETT-PACKARD COMPANY 
Intellectual Property Administration 
P.O. Box 272400 
Fort Collins, CO 80527-2400 



Andrea Acquaviva 



200208134-1 



4371 



EXAMINER 



RAHMAN, FAHMIDA 



ART UNIT 



PAPER NUMBER 



2116 

DATE MAILED: 07/25/2006 



Please find below and/or attached an Office communication concerning this application or proceeding. 



PTO-90C (Rev. 10/03) 



Off icg Action Summarv 


Application No. 

10/632,412 


Applicant(s) 

ACQUAVIVA ET AL. 


Examiner 

Fahmida Rahman 


Art Unit 

2116 





The MAILING DATE of this communication appears on the cover sheet with the correspondence address 
Period for Reply 



A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) OR THIRTY (30) DAYS, 
WHICHEVER IS LONGER, FROM THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1 .1 36(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 133). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1.704(b). 

Status 

1)^ Responsive to communication(s) filed on 08 May 2006 . 
2a)[S) This action is FINAL. 2b)D This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 11, 453 O.G. 213. 

Disposition of Claims 

4) I3 Claim(s) 1-20 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) D Claim(s) is/are allowed. 

6) E3 Claim(s) 1-20 is/are rejected. 

7) D Claim(s) is/are objected to. 

8) D Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) D The specification is objected to by the Examiner. 

10) ^ The drawing(s) filed on 31 July 2003 is/are: a)[3 accepted or b)D objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1.85(a). 
Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 

11) D The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 

Priority under 35 U.S.C. § 119 

12) D Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d) or (f). 
a)D All b)D Some * c)D None of: 

1 .□ Certified copies of the priority documents have been received. 

2. Q Certified copies of the priority documents have been received in Application No. . 

3. Q Copies of the certified copies of the priority documents have been received in this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 



Attachment(s) 

1) O Notice of References Cited (PTO-892) 

2) O Notice of Draftsperson's Patent Drawing Review (PTO-948) 

3) □ Information Disclosure Statement(s) (PTO-1449 or PTO/SB/08) 

Paper No(s)/Mail Date . 



4) O Interview Summary (PTO-413) 

Paper No(s)/Mail Date. . 

5) CD Notice of Informal Patent Application (PTO-152) 

6) □ Other: . 



U.S. Patent and Trademark Office 
PTOL-326 (Rev. 7-05) 



Office Action Summary 



Part of Paper No./Mail Date 01 182006 



Application/Control Number: 1 0/632,412 Page 2 

Art Unit: 21 16 

DETAILED ACTION 

1 . This final action is in response to communications filed on 5/8/2006. 

2. Claims 1, 2, 3, 4, 5, 10, 12, 14, 15, 16, 19 have been amended, no new claims 
have been added, no claims have been cancelled. Therefore, claims 1-20 are pending. 

Claim Rejections - 35 USC § 102 

The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form 
the basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 

Claims 1, 12, 16-18 are rejected under 35 U.S.C. 102(e) as being anticipated by Oehler 
et al (US Application Publication Number 2004/0003303). 

For claim 1 , Oehler et al teach the following limitations: 

In a real time operating system (310) for supporting a plurality of applications 

(1 17 is supported by OS. 117 gathers information from different sources. Therefore, OS 
must support the applications that are supported by OS), a processor (331 is System 
hardware that includes processor such as 202 a-d) and at least one hardware 
resource (331 and 333), the improvement comprising, in combination: 
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a) a power manager layer (the combination of 31 1, 313 and 321); and 

b) said power manager layer being arranged to receive real time input from the 
plurality of applications ([0052] mentions that 117 takes input from plurality of 
sources, which can be considered as applications. The power authority can update 
power table through an OS as mentioned in [0052]. Therefore, power tables receive real 
time input from plurality of applications through power authority and an OS), wherein 
real time input includes a current status and operational requirements of each of 
said plurality of applications running on the hardware platform (real time input 
provides power consumption information to update power table. Power consumption 
information is current status and operational requirement of system/application, since it 
is used to perform power management as mentioned in 709. [0052] mentions that real 
time input includes power consumption information to update the power tables. The 
power consumption information represents current and operational requirements, since 
the updated information represents that the current status of the system is alterable and 
the requirements for alteration are in the information); 

determine a power management adjustment using the received real time input 

(709); 

exchange information with said processor and said at least one hardware 
resource (lines 12-14 of [0036] of page 3 mention that 313 can tell the operating 
system when various components should be in particular power states. 313 needs to 
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access 451 to get the information about system components including system 
processor and hardware component as shown in Fig 4. The table 451 exchanges 
information to perform power management) to provide real time power management 
([0026] mentions that power management can be dynamic. Thus, the power 
management is real time power management) responsive to said information (steps 
707, 709, 81 1 show that the OS is updating power table. [0036] of page 3 mentions that 
ACPI OS itself control the component power state). 

For claim 12, Oehler et al teach the following limitations: 

A real time power management system (abstract) for a processor-driven hardware 
platform (Fig 1 and Fig 2) for supporting a plurality of applications (117 is 
supported by OS. 117 gathers information from different sources. Therefore, OS must 
support the applications that are supported by OS) said platform having at least one 
hardware resource (331 and 333) wherein said processor is characterized by a 
plurality of power states and said at least one hardware resource is characterized 
by a plurality of power states ([0039] of page 4 mentions that the components have 
plurality of power states. In addition, Fig 4 shows the plurality of power state for 
processor and hardware components), said power management system comprising, 
in combination: 

a) an operating system (310) for controlling said processor and said at least one 
hardware resource (lines 10-17 of [0036] of page 3); 
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b) said operating system including a power manager layer (313 and 311) arranged 
to receive real time input from the plurality of applications ([0052] mentions that 
117 takes input from plurality of sources, which can be considered as applications. The 
power authority can update power table as mentioned in [0052]. Therefore, power table 
receives real time input from plurality of applications through power authority), wherein 
real time input includes a current status and operational requirements of each of 
said plurality of applications running on the hardware platform (real time input 
provides power consumption information to update power table. Power consumption 
information is current status and operational requirement of system/application, since it 
is used to perform power management as mentioned in 709) 

select a processor power state and a power state of said at least one hardware 
resource (lines 12-14 of [0036] of page 3 mention that 313 can tell the operating 
system when various components should be in particular power states. 313 needs to 
access 451 to get the information about system components. The table 451 exchanges 
information with different components to update the power history. Lines 1-2 of [0038] of 
page 4 mention that the power authority is an application running on operating system) 
in response to said real time input ([0026] mentions that power management can be 
dynamic. Thus, the power management is real time power management as shown in 
805) from said at least one application (steps 707, 709, 811 show that the OS is 
updating power table. [0036] of page 3 mentions that ACPI OS itself control the 
component power state. Step 701 shows that the power authority is exchanging 
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information with OS and power table for power management. Thus, ACPI OS performs 
power management by taking input from power authority). 

For claim 16, Oehler et al teach the following limitations: 

A method for controlling power consumption (abstract) in a hardware platform (Fig 
1 and Fig 2) responsive to information from a plurality of applications (117 is 
supported by OS. 117 gathers information from different sources. Therefore, OS must 
support the applications that are supported by OS), said platform including a 
processor having a plurality of power states and at least one hardware resource 
characterized by a plurality of power states ([0039] of page 4 mentions that the 
components have plurality of power states. In addition, Fig 4 shows the plurality of 
power state for processor and hardware components), said method comprising the 
steps of: 

organizing said operating system (combination of 310 and 321) into a kernel (311), 
a driver layer (315), a hardware abstraction layer (ACPI Device Tree in ACPI Table 
325), and a power manager layer (combination of 313 and 325); 

applying one real time input from said at least one application to said power 
manager layer (steps 707, 709, 811 show that the OS is updating power table. [0036] 
of page 3 mentions that ACPI OS itself control the component power state. Step 701 
shows that the power authority is exchanging information with OS and power table for 
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power management. Thus, ACPI OS performs power management by taking input from 
power authority) wherein real time input includes a current status and operational 
requirements of each of said plurality of applications running on the hardware 
platform (real time input provides power consumption information to update power 
table. Power consumption information is current status and operational requirement of 
system/application, since it is used to perform power management as mentioned in 709. 
[0052] mentions that real time input includes power consumption information to update 
the power tables. The power consumption information represents current and 
operational requirements, since the updated information represents that the current 
status of the system is alterable and the requirements for alteration are in the 
information); 

determining a power management policy in said power manager layer in 
response to real time input (step 709 in Figure 7 mentions that the the power 
management is performed with updated power table values. Thus, the ACPI system 
determines the power management policy in ACPI OS depending on the input taken 
from power authority); 

communicating said power management policy from said power manager layer to 
said processor and said at least one hardware resource (Fig 4 shows the various 
power states for processor and hardware. Thus, the power management layer 
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communicates the power management information to the components including 
processors and hardware). 

For claims 17 and 18, note [0041] of page 4 and 451 , which shows about various power 
states of processor and hardware resources. 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

Claims 2-11,13-15,19 and 20 are rejected under 35 U.S.C. 1 03(a) as being 

unpatentable over Oehler et al (US Patent Application Publication 2004/0003303), in 

view of Intel ACPI-CA. 

For claim 2, [0038] of page 4 mentions that the power authority application receives 
message from OS. Lines 16-17 of [0037] of page 4 mention that the power table is an 
ACPI table. ACPI provides ACPI API to the OS. Thus, the communication between 
power authority application and ACPI OS should include API call. 
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The system of Oehler et al makes use of ACPI OS for power management. That 
includes API calls, since power management is performed by OS. However, Oehler et al 
do not explicitly mention API calls for power management. 

The Intel implementation of ACPI-CA provides varieties of API to the operating system. 
ACPI-CA provides high-level ACPI API to the operating system. The OS uses this API 
to implement power management, device configuration and thermal management. 
Table 1 of ACPI Component Architecture shows the API used for power management 
and device configuration. Thus, all the communications of power authority to ACPI OS 
should be through API. 

It would have been obvious to one ordinary skill in the art at the time the invention was 
made to combine the teachings of Oehler et al and ACPI-CA. One ordinary skill in the 
art would have been motivated to include ACPI-CA, since ACPI-CA is used by many 
open source operating systems including FreeBSD and Linux. 

For claim 3, the program call from power authority to ACPI OS must comprise the step 
whether the application is initiated. If the application is not running, no information can 
be gathered from that application. 

For claim 4, lines 9-11 of [0045] of page 4 mention that power authority creates a 
historical power consumption representation. Steps 707 and 809 mention that the 
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information is sent to OS. Thus, the utilization profile is sent to the ACPI OS power 
management code 313. 

For claim 5, Fig 7 and Fig 8 show that the power authority performs power management 
of hardware components through power table. Thus, there must be a notification from 
power authority to ACPI OS that a particular hardware resource need power 
management. In such a case, the power authority application will manage power to the 
resource by the API call, since the API call is necessary for power management in ACPI 
system. 

For claim 6, 451 comprises the hardware abstraction layer 401, 403, 405 and 407. 
Thus, 451 can be thought as a hardware abstraction layer. Since, 451 are part of ACPI, 
the API is necessary to implement power management, device configuration and 
thermal management. The OSPM 313 needs to exchange information with 451 through 
API call for power management. 

For claim 7, the combination of 315 and 317 is the driver layer. Since this is an ACPI 
OS system, the call should be performed through API for power management and 
device configuration. 

For claim 8, 451 in Figure 4 shows the processor and hardware power state selection 
mode. 
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For claim 9, [0044] of page 4 mentions that the resource is allocated by the power 
authority. Since power authority works in conjunction with ACPI OS, the power manager 
layer must have a corresponding resource allocation table to allocate the resource as 
specified by the power authority. 

For claim 10, the OS uses API for device configuration and power management. Thus, 
the device driver 315 receives API call containing power instructions for managing 
power of a resource. The device driver has to generate appropriate command to control 
power of that particular resource. 

For claim 11, it is well known in the art that ACPI system comprises ACPI namespace 
that exchanges information with device drivers to actuate the device. Since, ACPI 
namespace is a software database, the interaction has to be performed through 
program call. 

For claim 13, The system of Oehler et al makes use of ACPI OS for power 
management. That includes API calls, since power management is performed by OS. 
The call from power authority to power table has to include API, since accessing ACPI 
power table should include ACPI API call. 

However, Oehler et al do not explicitly mention API calls for power management. 
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The Intel implementation of ACPI-CA provides varieties of API to the operating system. 
ACPI-CA provides high-level ACPI API to the operating system. The OS uses this API 
to implement power management, device configuration and thermal management. 
Table 1 of ACPI Component Architecture shows the API used for power management 
and device configuration. Thus, all the communications of power authority to ACPI OS 
should be through API. 

It would have been obvious to one ordinary skill in the art at the time the invention was 
made to combine the teachings of Oehler et al and ACPI-CA. One ordinary skill in the 
art would have been motivated to include ACPI-CA, since ACPI-CA is used by many 
open source operating systems including FreeBSD and Linux. 

For claim 14, the program call from power authority to ACPI OS should have a start and 
end notification. Lines 7-9 of [0045] of page 4 mention that the OS provides information 
to power authority during varying fixed interval time. Thus, there should be a notification 
that the power authority to acquire information from OS. In other words, there must be a 
notification that the power authority application started and ended the acquiring of 
information. 

For claim 15, Fig 7 and Fig 8 show that the power authority performs power 
management of hardware components through power table. Thus, there must be a 
notification from power authority to ACPI OS that a particular hardware resource need 
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power management. In such a case, the power authority application will manage power 
to the resource by the API call, since the API call is necessary for power management 
in ACPI system. 

For claims 19 and 20, the system of Oehler et al makes use of ACPI OS for power 
management. That includes API calls, since power management is performed by OS. 
However, Oehler et al do not explicitly mention API calls for power management. 

The Intel implementation of ACPI-CA provides varieties of API to the operating system. 
ACPI-CA provides high-level ACPI API to the operating system. The OS uses this API 
to implement power management, device configuration and thermal management. 
Table 1 of ACPI Component Architecture shows the API used for power management 
and device configuration. Thus, all the communications of power authority to ACPI OS 
should be through API. The API call should transfer the input from power authority to 
ACPI power table. 

It would have been obvious to one ordinary skill in the art at the time the invention was 
made to combine the teachings of Oehler et al and ACPI-CA. One ordinary skill in the 
art would have been motivated to include ACPI-CA, since ACPI-CA is used by many 
open source operating systems including FreeBSD and Linux. 
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Response to Arguments 

Applicant's arguments filed on 5/8/2006 have been fully considered but they are not 
persuasive. 

Applicant argues that Oehler failed to teach "power manager layer being arranged to 
receive real time input from a plurality of applications" as recited in independent claims 
1 and 12. Applicant argues that Oehler does not teach that the code 313 or table 451 
receiving input from 1 1 7 or 301 . 

Examiner disagrees. 1 17 is supported by OS. The plurality of applications providing real 
time input to power authority was admitted by applicant in lines 7-12 of page 12 of 
remarks. Applicant admits that 117 receives message from plurality of systems, or 
applications. The information received by power authority is sent to the OS to update 
the tables are described in [0052]. Therefore Oehler teaches that the tables receive 
input from the power authority through OS. 

Applicant further argues that Oehler fails to teach that the 313 or 451 receive real time 
input from a plurality of applications. 

Examiner disagrees. 451 receives input from 117 through an OS, which receives 
messages from plurality of applications. Therefore, 451 receive real time input from 
plurality of applications through OS. In short, the power authority of Oehler receives real 
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time input from plurality of applications, which is sent to an OS to update the power 
tables. The part of OS that is used to update power tables can be considered a part of 
power manager layer. 

Applicant further argues that Oehler fails to teach a power manager layer receiving real 
time input comprising a current status and operational requirements for an application or 
a plurality of applications. 

Examiner disagrees. The real time input received by power authority updates the power 
tables through OS. The generation of power consumption information is shown in Fig 8, 
which is used to update power tables. The optimal power management scheme 
(operational requirements) at 805 is based on usage patterns (current status). 
Therefore, the information representing optimal power management schemes are the 
operational requirements for that particular power states of the components, which itself 
represents the current status of the components in that the component is not presently 
in optimal power scheme. Therefore, the fact that OS received updated value to update 
power tables represents the current status that the system is not the optimal power 
mode, and the operational requirements that the system needs to be shifted in a 
desirable power state. 

Applicant further argues that Oehler fails to teach the communication between power 
authority and ACPI. 
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Examiner disagrees. [0038] mentions that power authority can manage the underlying 
ACPI functionality. Therefore, power authority communicates with ACPI through OS, be 
it code 31 3 or 31 1 or other. 

Applicant further argues that there is no motivation behind combining ACPI-CA and 
Oehler. The fact that ACPI-CA is readily available and compatible with many open 
source operating system is a motivating factor for ordinary skill in the art. ACPI and 
ACPI-CA is compatible, which is a desirable feature to modify Oehler. 

Conclusion 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy 
as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 
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Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Fahmida Rahman whose telephone number is 571-272- 
8159. The examiner can normally be reached on Monday through Friday 8:30 - 5:30. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Lynne Browne can be reached on 571-272-3670. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published 
applications may be obtained from either Private PAIR or Public PAIR. Status 
information for unpublished applications is available through Private PAIR only. For 
more information about the PAIR system, see http://pair-direct.uspto.gov. Should you 
have questions on access to the Private PAIR system, contact the Electronic Business 
Center (EBC) at 866-217-9197 (toll-free). 

Fahmida Rahman 

Examiner 
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